LLM 평가셋을 실제 실패 사례로 만드는 방법

목차

• #평가셋이 실제 사용보다 쉬워지는 이유
• #실패를 수집하기 전에 개인정보 경계를 만든다
• #실패 사례와 평가 Case는 다르다
• #최소 재현 입력으로 정리한다
• #실패 원인을 계층별로 분류한다
• #정답 문자열보다 불변 조건을 기록한다
• #근거와 출처를 Ground Truth에 포함한다
• #여러 정답이 가능한 질문은 Rubric으로 평가한다
• #금지 행동과 안전 실패를 명시한다
• #결정적 평가와 Model Judge를 분리한다
• #재구성한 평가 Case Schema
• #재구성한 Grader 예제
• #Dataset Split과 중복을 관리한다
• #운영 빈도와 위험도를 함께 반영한다
• #새 실패를 Regression으로 승격하는 흐름
• #평가 실행 환경을 Versioning한다
• #결과를 Aggregate할 때 숨기면 안 되는 것
• #평가셋 자체의 품질을 검토한다
• #마무리
• #참고 자료
• #관련 노트

평가셋이 실제 사용보다 쉬워지는 이유

기능을 처음 만들 때 평가 질문은 개발자가 작성한다.

Q: 비밀번호 재설정 방법을 알려 줘.
A: 설정 > 보안 > 비밀번호 재설정으로 이동합니다.

문장이 짧고 문법적으로 정확하며 필요한 정보가 한 문서에 있다. 반면 운영 요청은 다음과 같다.

어제부터 로그인이 안 되는데 비번 바꿨고 회사 계정이라 SSO인가 그걸로
되는 것 같기도 해요. 모바일에서는 1042 비슷한 오류가 뜨고 웹은 계속
처음으로 돌아가요. 계정 잠긴 건가요? 관리자한테 말해야 하나요?

실제 입력에는 여러 의도, 부정확한 code, 시간 정보와 제품 환경이 섞여 있다. 필요한 답이 corpus에 없거나 추가 질문이 필요할 수도 있다.

평가셋이 쉬워지는 흔한 이유는 다음과 같다.

• 문서에 있는 표현을 그대로 질문에 사용한다.
• 정답이 항상 존재한다.
• 짧고 독립적인 single-turn만 넣는다.
• 한국어 띄어쓰기, 오타와 구어체가 없다.
• 권한과 개인정보 조건을 제외한다.
• Tool timeout과 부분 실패를 재현하지 않는다.
• 공격 입력이나 상충하는 문서를 빼 놓는다.
• 개발자가 이미 잘 작동하는 사례만 선택한다.

flowchart LR
    D[깨끗한 Demo Questions] --> H[높은 Offline 점수]
    P[복잡한 Production Inputs] --> F[실제 실패]
    H -. 대표성 부족 .-> F

실패를 수집하기 전에 개인정보 경계를 만든다

운영 로그를 평가셋으로 복사하면 사용자 대화, 이메일, 전화번호, access token과 내부 URL이 장기 보존될 수 있다. 수집 전에 허용 범위를 정한다.

Production trace
  -> 접근 권한이 있는 triage
  -> 민감 정보 탐지·삭제·재구성
  -> 최소 재현 case
  -> 검토된 private eval dataset

다음 값은 기본적으로 그대로 복사하지 않는다.

• 이름, 이메일, 전화번호와 주소
• 고객 ID, 주문 ID와 결제 정보
• Access token, API key, cookie와 session
• 내부 hostname, repository URL과 credential path
• 사용자가 올린 원본 문서 전체
• Model의 숨겨진 instruction이나 secret configuration

단순 masking만으로 충분하지 않을 수 있다.

원문: 김찬호 고객의 주문 ORD-839201이 서울 강남점에서 실패
나쁜 익명화: 김** 고객의 주문 ORD-******가 서울 강남점에서 실패
재구성: 사용자 A의 주문 EXAMPLE-17이 지점 B에서 실패

고유한 사건 조합으로 재식별될 수 있으므로 실패에 필요한 구조만 남기고 사실값을 가상 값으로 바꾼다.

type RedactionRecord = {
  sourceIncidentId: string;
  redactionVersion: string;
  removedClasses: string[];
  syntheticReplacements: string[];
  reviewedBy: string;
  reviewedAt: string;
};

원본 incident와 평가 case의 연결은 제한된 mapping store에 두고, 일반 개발자는 재구성한 case만 보게 한다.

실패 사례와 평가 Case는 다르다

운영 trace 한 건에는 원인과 무관한 정보가 많다.

Incident
  - 대화 18 turns
  - 검색 결과 50개
  - tool call 12회
  - model retry 3회
  - 최종 잘못된 답변

이를 그대로 평가하면 비용이 크고 어느 조건이 실패를 일으켰는지 모른다. 평가 case는 재현 가능한 입력과 판정 기준으로 정리한 artifact다.

type IncidentToEval = {
  incidentRef: string;
  reproduced: boolean;
  failureLayer: string;
  minimalConditions: string[];
  evalCaseId?: string;
};

재현되지 않는 실패도 버리지 않는다. needs_observability로 분류해 다음 발생 때 필요한 trace field를 추가할 수 있다.

최소 재현 입력으로 정리한다

Software bug의 최소 재현 예제처럼 LLM 실패에서도 입력을 줄여 본다. 단, 줄이는 과정에서 실제 난이도를 제거하지 않는다.

원본 실패 조건
  긴 대화 + 구버전 문서 + 비슷한 오류 코드 + 모호한 대명사

하나씩 제거해 failure가 유지되는지 확인한다.

긴 대화 제거      -> 여전히 실패
구버전 문서 제거  -> 성공으로 바뀜
비슷한 코드 제거  -> 성공으로 바뀜
대명사 명확화     -> 여전히 실패

최소 조건은 구버전 문서와 비슷한 오류 코드가 함께 검색됨일 수 있다. 이를 case fixture에 보존한다.

minimal_conditions:
  - active document contains PAY-1042
  - expired document contains PAY-1041 with similar wording
  - query mentions "1042 비슷한 오류"

그러나 production distribution을 평가하는 대표 case에는 원래의 긴 문장과 오타도 필요하다. 두 종류를 나눈다.

Diagnostic case: 원인을 좁힌 최소 입력
Representative case: 실제 사용 형태를 보존한 비식별 입력

Diagnostic은 regression 원인을 찾기 쉽고 representative는 전체 체감 성능을 반영한다.

실패 원인을 계층별로 분류한다

모든 실패를 MODEL_BAD_ANSWER로 표시하면 model 교체만 반복하게 된다.

flowchart TD
    F[Observed Failure] --> I{Input 이해?}
    I --> R{정답 Evidence 검색?}
    R --> K{정답이 Context에 포함?}
    K --> G{근거를 올바르게 사용?}
    G --> T{Tool과 정책 준수?}
    T --> O{출력 전달 성공?}

실패 taxonomy 예시는 다음과 같다.

하나의 incident에 여러 category가 있을 수 있다. Primary cause와 contributing cause를 구분한다.

{
  "primaryFailure": "RANKING_HARD_NEGATIVE",
  "contributingFailures": ["GENERATION_UNSUPPORTED_CLAIM"]
}

정답 문자열보다 불변 조건을 기록한다

자연어 답변은 같은 의미를 여러 방식으로 표현할 수 있다. Exact string 비교는 좋은 답도 실패시킨다.

Expected exact string:
"PAY-1042 오류에서는 자동으로 재시도하지 마세요."

동일하게 허용할 수 있는 답:
"이 오류는 재호출하지 말고 기존 operation 결과를 먼저 확인해야 합니다."

답변이 만족해야 할 사실과 금지할 주장을 나눈다.

expected_facts:
  - id: no_automatic_retry
    statement: PAY-1042는 자동 재시도 대상이 아니다
    evidence_ids: [policy-pay-1042]
  - id: reconcile_first
    statement: 기존 operation 결과를 먼저 확인한다
    evidence_ids: [runbook-reconcile]

forbidden_claims:
  - 최대 2회 자동 재시도한다
  - 새 operation ID로 다시 결제한다

형식과 행동 불변 조건도 있다.

behavior:
  must_ask_clarification: false
  must_cite_sources: true
  allowed_tools: [operation.read]
  forbidden_tools: [payment.create, email.send]
  max_tool_calls: 2

LLM system 평가에서는 답변 text뿐 아니라 tool trace, retrieval evidence와 latency를 함께 판정한다.

근거와 출처를 Ground Truth에 포함한다

Expected answer만 있으면 검색 pipeline을 평가하기 어렵다. 필요한 source span을 표시한다.

type EvidenceExpectation = {
  sourceId: string;
  sourceVersion: string;
  contentHash: string;
  spans: Array<{ start: number; end: number }>;
  supportsFactIds: string[];
};

{
  "sourceId": "payment-policy-v6",
  "sourceVersion": "6",
  "contentHash": "sha256:example",
  "spans": [{ "start": 820, "end": 1044 }],
  "supportsFactIds": ["no_automatic_retry"]
}

그러면 단계별로 확인할 수 있다.

1. 정답 source가 index에 있는가
2. Retriever candidate에 포함되는가
3. Reranker가 상위로 올리는가
4. Context assembly가 span을 보존하는가
5. 답변 claim이 해당 span을 인용하는가

Source가 바뀌면 hash mismatch로 fixture가 stale한 것을 알 수 있다. 문서를 무조건 최신판으로 바꾸지 않고, policy 변경이 expected behavior를 바꿨는지 domain owner가 검토한다.

이 구조는 AI 응답에 출처와 근거를 연결하는 방법의 데이터 모델과 연결된다.

여러 정답이 가능한 질문은 Rubric으로 평가한다

코드 리뷰, 요약과 설명은 하나의 gold text를 만들기 어렵다. Rubric은 평가 관점을 구체적인 수준으로 나눈다.

rubric:
  - criterion: correctness
    weight: 0.4
    levels:
      0: 핵심 원인이 틀리거나 근거 없는 해결책
      1: 원인은 맞지만 중요한 예외 누락
      2: 원인과 예외를 근거에 맞게 설명
  - criterion: actionability
    weight: 0.3
    levels:
      0: 실행 가능한 단계 없음
      1: 일부 단계는 있으나 순서 또는 확인 누락
      2: 확인-조치-검증 순서가 명확
  - criterion: safety
    weight: 0.3
    levels:
      0: 승인 없는 변경이나 비밀 노출
      1: 위험 경고는 있으나 통제 불명확
      2: 권한과 승인 경계를 준수

좋음, 자세함처럼 모호한 기준보다 관찰 가능한 차이를 쓴다. 각 level에 positive와 negative 예시를 두되 특정 문구를 흉내 내는 것이 점수로 이어지지 않게 한다.

여러 human annotator가 같은 sample을 독립 평가해 agreement를 확인한다. Agreement가 낮다면 model보다 rubric이 모호할 가능성이 있다.

Annotator A: correctness 2
Annotator B: correctness 0
-> 불일치 사유 검토
-> evidence 또는 level 정의 보완

금지 행동과 안전 실패를 명시한다

Expected output만 검사하면 답은 맞지만 위험한 tool을 호출한 실행이 통과할 수 있다.

{
  "expected": {
    "facts": ["계정 잠금 정책 설명"]
  },
  "forbidden": {
    "tools": ["account.unlock", "email.send"],
    "dataClasses": ["access_token", "other_tenant_profile"],
    "claims": ["관리자 승인 없이 잠금 해제 완료"]
  }
}

답이 없을 때는 추측보다 abstention이 정답일 수 있다.

no_answer_case:
  expected_behavior:
    - 답이 문서에 없음을 명시
    - 필요한 추가 정보 질문
    - 존재하지 않는 정책을 만들지 않음

Tool failure도 평가한다.

Given  operation.read가 timeout
Then   결제 생성으로 대체하지 않는다
And    결과가 불명확함을 표시한다
And    같은 operation ID로만 안전한 조회를 재시도한다

안전 실패는 낮은 품질이 아니라 요구되는 행동이다.

결정적 평가와 Model Judge를 분리한다

가능한 것은 코드로 직접 검사한다.

의미적 정확성이나 글의 명료함처럼 결정하기 어려운 부분에 model judge를 사용한다.

Final evaluation
  deterministic gates
    AND semantic rubric score
    AND no critical safety violation

Model judge도 오류와 편향이 있다.

• 답변 길이를 품질로 오인할 수 있다.
• 자신과 비슷한 문체를 선호할 수 있다.
• Prompt injection이 포함된 candidate에 영향받을 수 있다.
• 순서에 따라 A/B 선호가 바뀔 수 있다.
• Rubric보다 일반 지식을 사용해 판정할 수 있다.

Judge에게 user answer와 reference를 명확히 분리하고 structured score와 evidence를 요구한다. 일부 sample을 human review로 calibration한다.

재구성한 평가 Case Schema

다음은 특정 framework에 종속되지 않은 TypeScript 예시다.

type EvalCase = {
  id: string;
  version: number;
  title: string;
  source: {
    kind: "PRODUCTION_FAILURE" | "RED_TEAM" | "DESIGNED";
    incidentRef?: string;
  };
  category: string[];
  severity: "LOW" | "MEDIUM" | "HIGH" | "CRITICAL";
  input: {
    messages: Array<{ role: "user" | "assistant"; content: string }>;
    fixtures: FixtureRef[];
  };
  expected: {
    facts: ExpectedFact[];
    evidence: EvidenceExpectation[];
    behaviors: ExpectedBehavior[];
  };
  forbidden: {
    claims: string[];
    tools: string[];
    dataClasses: string[];
  };
  rubric?: Rubric;
  metadata: {
    redactionVersion: string;
    owner: string;
    createdAt: string;
    lastReviewedAt: string;
  };
};

Fixture도 immutable하게 versioning한다.

type FixtureRef = {
  fixtureId: string;
  version: string;
  contentHash: string;
  kind: "DOCUMENT_SET" | "TOOL_RESPONSE" | "DATABASE_SNAPSHOT";
};

평가 실행마다 어떤 fixture와 index가 사용됐는지 남겨야 결과를 재현할 수 있다.

재구성한 Grader 예제

먼저 critical gate를 결정적으로 검사한다.

type RunTrace = {
  answer: string;
  citations: Citation[];
  toolCalls: ToolCall[];
  accessedDataClasses: string[];
  latencyMs: number;
};

function gradeCriticalGates(testCase: EvalCase, trace: RunTrace): GateResult[] {
  return [
    {
      name: "forbidden_tools",
      passed: trace.toolCalls.every(
        (call) => !testCase.forbidden.tools.includes(call.name),
      ),
    },
    {
      name: "forbidden_data",
      passed: trace.accessedDataClasses.every(
        (kind) => !testCase.forbidden.dataClasses.includes(kind),
      ),
    },
    {
      name: "citation_sources",
      passed: citationsAreAllowed(trace.citations, testCase.expected.evidence),
    },
  ];
}

Expected fact는 reference span과 answer를 judge에 주되, 출력 schema를 고정한다.

type FactGrade = {
  factId: string;
  supported: boolean;
  contradicted: boolean;
  answerSpan?: string;
  reason: string;
};

async function gradeRun(testCase: EvalCase, trace: RunTrace): Promise<EvalResult> {
  const gates = gradeCriticalGates(testCase, trace);
  if (gates.some((gate) => !gate.passed && gate.critical)) {
    return { status: "FAIL", gates, semanticScore: null };
  }

  const factGrades = await semanticJudge.gradeFacts({
    answer: trace.answer,
    expectedFacts: testCase.expected.facts,
    evidence: loadExpectedEvidence(testCase),
    rubricVersion: "fact-grader-v4",
  });

  return combineGrades({ gates, factGrades, rubric: testCase.rubric });
}

Judge 결과도 원문 답변, judge model, prompt version과 timestamp에 묶는다. 같은 결과를 다른 judge로 재평가할 수 있어야 한다.

Dataset Split과 중복을 관리한다

평가 실패를 보고 prompt를 수정한 뒤 같은 case 점수가 오르는 것은 필요하지만, 그 case에만 과적합할 수 있다.

Regression set
  이미 알려진 실패를 절대 되풀이하지 않는 gate

Development set
  Prompt와 pipeline을 반복 조정하는 용도

Held-out set
  최종 선택 전까지 보지 않는 일반화 확인

Shadow production set
  최근 분포 변화 확인

비슷한 incident를 무작위로 split하면 거의 동일한 질문이 train과 held-out에 들어간다. 사용자, template, 문서 family 또는 시간 기준으로 group split한다.

type DedupSignature = {
  normalizedIntent: string;
  fixtureFamily: string;
  failureCategory: string;
  semanticFingerprint: string;
};

Exact hash, normalized text와 embedding similarity를 함께 사용해 near-duplicate를 찾고 사람이 검토한다. Embedding만으로 자동 삭제하면 중요한 숫자·부정 차이를 같은 case로 오인할 수 있다.

평가 case를 prompt나 model 학습 데이터로 사용했다면 contamination metadata를 남긴다.

exposure:
  used_for_prompt_development: true
  used_for_fine_tuning: false
  first_exposed_at: 2026-06-10

운영 빈도와 위험도를 함께 반영한다

발생 빈도가 높은 사소한 실패와 드문 치명적 실패를 하나의 평균으로 합치면 우선순위가 흐려진다.

priority weight
  = production frequency
  × user impact
  × reversibility
  × detection difficulty

수학적으로 정확한 위험 공식이라기보다 정렬 기준이다.

Critical safety case는 가중 평균 98점에 묻히지 않게 별도 must-pass suite로 둔다.

Dataset 구성도 production frequency만 그대로 따라가면 드문 edge case가 사라진다. 대표 분포 suite와 위험 중심 challenge suite를 분리한다.

Representative suite -> 실제 체감 평균
Regression suite     -> 알려진 실패 방지
Safety suite         -> critical invariant
Challenge suite      -> 경계 조건과 미래 위험

HELM은 accuracy 한 축만이 아니라 robustness, fairness, toxicity와 efficiency 등 여러 관점에서 model을 평가하는 접근을 제시한다. 제품 평가도 하나의 aggregate accuracy보다 여러 요구사항을 드러내는 편이 낫다.

새 실패를 Regression으로 승격하는 흐름

실패가 발생할 때마다 무조건 case를 추가하면 dataset이 중복과 오래된 정책으로 부풀어 오른다. Triage workflow를 둔다.

stateDiagram-v2
    [*] --> Reported
    Reported --> Reproduced: 고정 환경에서 재현
    Reported --> NeedsTelemetry: 근거 부족
    Reproduced --> Redacted: 민감 정보 제거
    Redacted --> Labeled: 원인·expected·forbidden 작성
    Labeled --> Reviewed: domain·privacy 검토
    Reviewed --> Active: eval suite 편입
    Active --> Updated: 정책 또는 fixture 변경
    Active --> Retired: 더 이상 유효하지 않음

각 단계의 owner가 다를 수 있다.

owners:
  reproduction: ai_engineering
  expected_behavior: domain_owner
  privacy_review: privacy_or_security
  grader_review: evaluation_owner

수정이 merge되기 전에 새 case가 이전 버전에서는 실패하고 수정 버전에서는 통과하는지 확인한다. 처음부터 양쪽에서 통과했다면 case가 실패를 포착하지 못했거나 환경이 다르다.

평가 실행 환경을 Versioning한다

Model 이름만 기록하면 결과를 재현할 수 없다.

type EvalRunManifest = {
  runId: string;
  datasetVersion: string;
  caseIds: string[];
  model: string;
  modelParameters: Record<string, unknown>;
  systemPromptVersion: string;
  toolSchemaVersion: string;
  retrievalIndexVersion: string;
  chunkPolicyVersion: string;
  rerankerVersion?: string;
  policyVersion: string;
  graderVersion: string;
  codeRevision: string;
  startedAt: string;
};

Temperature가 0이어도 service와 model 구현이 완전히 결정적이라는 보장은 없다. 중요한 case는 여러 번 실행해 pass rate와 variance를 본다.

Case A: 10/10 pass
Case B: 6/10 pass

한 번 통과한 B를 안정적이라고 볼 수 없다. Tool과 network fixture는 replay 가능하게 만들고, 실제 외부 API를 사용하는 integration suite는 별도로 구분한다.

비용과 latency도 같은 manifest에서 측정한다. 품질이 조금 오른 대신 token이 5배 늘었다면 release 결정에 필요한 trade-off다.

결과를 Aggregate할 때 숨기면 안 되는 것

평균 점수 하나는 보기 쉽지만 중요한 회귀를 숨긴다.

전체 점수: 88 -> 90

Semantic QA: 91 -> 95
Exact code: 89 -> 92
No-answer:   86 -> 87
Safety:     100 -> 80  <- 전체 평균에서 묻힘

결과 report에는 다음을 포함한다.

• 전체와 category별 pass rate
• Severity별 failure 수
• 이전 baseline 대비 새 failure와 fixed failure
• Case별 반복 실행 variance
• Retrieval, tool, generation 단계별 실패 분포
• p50/p95 latency와 token·tool cost
• Critical gate 위반 목록
• Human review가 필요한 judge disagreement

type RegressionDiff = {
  newlyPassing: string[];
  newlyFailing: string[];
  unchangedPassing: string[];
  unchangedFailing: string[];
  criticalFailures: string[];
};

Release gate는 단순 overall >= 0.9보다 명시적이어야 한다.

release_gate:
  critical_safety_failures: 0
  known_regressions: 0
  representative_pass_rate_min: 0.90
  p95_latency_increase_max_percent: 15
  cost_increase_max_percent: 20

숫자는 설명용 예시다. 제품 SLA와 위험 허용도에 맞게 정한다.

평가셋 자체의 품질을 검토한다

평가셋도 code처럼 bug와 부채가 생긴다.

잘못된 expected answer
삭제된 정책을 계속 요구
Fixture hash mismatch
너무 모호한 rubric
특정 model 문체에만 유리한 judge
같은 case의 대량 중복
민감 정보가 남은 input
항상 통과하거나 항상 실패하는 무의미한 case

주기적으로 다음을 audit한다.

1. Domain owner가 expected behavior의 현재 유효성을 확인한다.
2. Privacy scanner와 사람이 민감 정보를 재검토한다.
3. Source hash와 citation span이 실제 fixture에 맞는지 검사한다.
4. Annotator agreement가 낮은 rubric을 수정한다.
5. 신규 production query distribution과 category 비율을 비교한다.
6. 오래된 model-specific workaround를 제거한다.
7. Retired case를 삭제하지 않고 이유와 version을 남긴다.

review:
  status: active
  domain_reviewed_at: 2026-08-01
  privacy_reviewed_at: 2026-08-01
  next_review_at: 2026-11-01
  known_limitations:
    - 모바일 OCR 입력 변형은 아직 포함하지 않음

평가 범위의 빈칸을 문서화하는 것도 중요하다. 측정하지 않은 것을 높은 점수가 증명한다고 해석하지 않는다.

마무리

좋은 LLM 평가셋은 예쁜 질문과 모범 답안을 모아 놓은 showcase가 아니다. 운영에서 사용자가 실제로 겪은 실패를 안전하게 재구성하고, 앞으로 같은 실패를 어떤 조건에서 막아야 하는지 실행 가능한 계약으로 만든 것이다.

실패 로그를 그대로 저장하지 말고, 실패를 일으킨 조건과 지켜야 할 불변 조건을 보존한 versioned regression case로 바꾼다.

실무 적용 기준은 다음과 같다.

1. 운영 trace를 평가에 사용하기 전 개인정보와 secret 경계를 정한다.
2. 실제 값은 masking보다 구조를 보존한 가상 값으로 재구성한다.
3. Incident와 재현 가능한 eval case를 분리한다.
4. Diagnostic 최소 case와 representative case를 함께 둔다.
5. 실패 원인을 ingestion, retrieval, generation, tool, policy와 runtime으로 분류한다.
6. Exact answer 대신 expected fact와 forbidden claim을 기록한다.
7. 정답 source version, hash와 evidence span을 ground truth에 포함한다.
8. 열린 답변은 구체적인 level을 가진 rubric으로 평가한다.
9. Tool, data access와 unsafe claim을 critical gate로 검사한다.
10. 가능한 조건은 결정적 code로, 의미 평가는 보정된 judge로 평가한다.
11. Regression, development, held-out와 shadow set을 분리한다.
12. Production 빈도와 critical risk suite를 별도로 관리한다.
13. 새 case가 이전 구현에서 실패하고 수정 구현에서 통과하는지 확인한다.
14. Model뿐 아니라 prompt, tool, index, policy와 grader version을 기록한다.
15. 평균과 함께 category, severity, variance, latency와 비용을 본다.
16. Dataset 자체도 domain·privacy·중복과 coverage 관점에서 audit한다.

평가셋은 한 번 만들어 고정하는 시험지가 아니라 제품이 실패를 학습하는 기억이다. 실제 실패가 안전하게 regression case로 남을 때 model과 pipeline을 바꿔도 같은 문제를 반복하지 않을 근거가 생긴다.

참고 자료

• Holistic Evaluation of Language Models
• Stanford CRFM - HELM
• BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models
• SWE-bench: Can Language Models Resolve Real-World GitHub Issues?

관련 노트

• 구조화 출력으로 LLM 응답 파싱 안정화하기
• 에이전트 재시도와 멱등성
• RAG에서 Chunk 크기를 정하는 기준
• Embedding 유사도만으로 검색하면 부족한 이유
• Hybrid Search로 키워드와 의미 검색 결합하기
• Reranker를 추가할 때 얻는 것과 비용
• 프롬프트 인젝션을 데이터와 명령 분리로 줄이기
• 환각을 없애기보다 검증 경로를 설계하기
• AI 응답에 출처와 근거를 연결하는 방법